I don't know why the validate step is failing. @corneliouzbett any ideas?

I don't know why the validate step is failing. @corneliouzbett any ideas?

Secrets are not passed to the runner when a workflow is triggered from a forked repository. So both username and password will be empty in the settings.xml. This is a security measure to prevent unauthorized access to sensitive data.

I believe, we don't need secrets for the validation step for this repo but we need for private repos.

I've added a PR here to conditionally, skip set the setting.xml step using the input variable use-secrets which is false by default.

@corneliouzbett @ibacher , the PR to fix the workflow is merged.

Shouldn't it be a complete Ozone archetype which sets up the distro sub module but will also bring the run/ resources upon build?

The idea of the archetype is to make it easier to setup distro-specific projects, since that's what there will be multiple versions of, so this is designed to produce something like ozone-distro-cambodia or ozone-kenyahmis. Do we have a use-case for multiple things with a distro submodule that pull in the run resources on build?

This adds some overhead to maintain duplicated version of the scripts files. Is there a way to reuse the existing actual Ozone resources as archetype resources? Or the opposite, Ozone to directly use the archetype resources?

We can probably abuse the fact that they're all submodules of a single project to do something.

This is modeled pretty concretely on what we're already doing with distributions (go-to-scripts-dir.sh needs to be filtered and then set-ozone-dir.sh relies on go-to-scripts-dir.sh being in the same folder), so it's not added maintenance over-and-above what already happens with ozone-cambodia or ozone-kenyahmis.

The location of the Maven Wrapper is the root directory.

Yeah, that's trivial to do, although I think putting the wrapper in a sub-directory is a little odd. The README for the generated projects uses instructions without having the Maven Wrapper in the scripts dir, but that's also fixable.

For the tests here to work, I need the Maven job to run the install step and not just the verify step. Is there a way to do that?

The problem is that the archetype includes a default integration test that actually needs things to be installed locally to work.

For the tests here to work, I need the Maven job to run the install step and not just the verify step. Is there a way to do that?

Yes, by modifying this to run install or take input variable maven-phase which runs verify by default.

Here is the PR to enable that.

The idea of the archetype is to make it easier to setup distro-specific projects, since that's what there will be multiple versions of, so this is designed to produce something like ozone-distro-cambodia or ozone-kenyahmis. Do we have a use-case for multiple things with a distro submodule that pull in the run resources on build?

@ibacher , so I just want to make sure that by default the "distribution" that will use this artefact will inherit/use/depend on the whole ozone project, not only the ozone-distro part, as we need the projects to be able to run the suite.

We can probably abuse the fact that they're all submodules of a single project to do something.

This is modeled pretty concretely on what we're already doing with distributions (go-to-scripts-dir.sh needs to be filtered and then set-ozone-dir.sh relies on go-to-scripts-dir.sh being in the same folder), so it's not added maintenance over-and-above what already happens with ozone-cambodia or ozone-kenyahmis.

Well, it does add a little bit of maintenance in the sense that it wasn't ours to do before. Now the file is hosted in the repo, that's upon us to maintain the 2 versions.
I'm ok with having this duplication right now. And see to improve it later. Anyway some of those scripts are already duplicated in Ozone Docker Compose too. A little piece of work there.

@rbuisson So the projects created by this archteyp use the ozone-distro-parent as a parent. ozone-distro-parent adds the full Ozone distribution as a dependency and the various default steps to work with it.

Yeah, that's trivial to do, although I think putting the wrapper in a sub-directory is a little odd.

I wanted to keep the root directory as clean as possible. But if that's an unusual thing to do and Maven Wrapper is 99% of the time located at the root folder, let's do have it there. We can modify Ozone itself accordingly in a follow up commit.

For some reason the final package ends up missing the readme/impl-guide.md file.

myOzone/
├── README.md
├── config
│   └── openmrs
│       ├── frontend_config
│       └── initializer_config
├── pom.xml
└── scripts
    ├── go-to-scripts-dir.sh
    ├── mvnw
    ├── mvnw.cmd
    ├── set-ozone-dir.sh
    └── start-ozone.sh

Re: readme/impl-guide.md: My fault. The archetype only picks up on files described in the src/main/resources/META-INF/maven/archetype-metadata.xml descriptor. I mistakenly left that out.

Also, the scripts have been removed from this PR, but they're added back with #42.

@ibacher do you plan to send a PR on Ozone Docs too?

@rbuisson PR for docs is here.